Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/telecomm/sticpsrc.lzh/DOC/SETTINGS.ARC/SETTINGS.TXT

Text File | 1990-06-03 | 20KB | 381 lines

_✓1.  _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓B_✓u_✓f_✓s_✓i_✓z_✓e, _✓P_✓a_✓c_✓l_✓e_✓n, _✓M_✓a_✓x_✓f_✓r_✓a_✓m_✓e, _✓M_✓T_✓U, _✓M_✓S_✓S _✓a_✓n_✓d _✓W_✓i_✓n_✓d_✓o_✓w

Many NET users are confused by these parameters and  do  not
know  how  to  set  them  properly.  This section will first
review these parameters  and  then  discuss  how  to  choose
values  for  them.  Special  emphasis  is  given to avoiding
interoperability problems that may appear when communicating
with non-NET implementations of AX.25.

_✓1._✓1.  _✓H_✓a_✓r_✓d_✓w_✓a_✓r_✓e _✓P_✓a_✓r_✓a_✓m_✓e_✓t_✓e_✓r_✓s

_✓1._✓1._✓1.  _✓B_✓u_✓f_✓s_✓i_✓z_✓e

This parameter is required by most of  NET's  built-in  HDLC
drivers  (e.g.,  those for the DRSI PCPA and the Paccomm PC-
100). It specifies the size of the buffer  to  be  allocated
for  each  receiver port. HDLC frames larger than this value
cannot be received.

There is no default b✓b✓b✓bu✓u✓u✓uf✓f✓f✓fs✓s✓s✓si✓i✓i✓iz✓z✓z✓ze✓e✓e✓e; it must  be  specified  in  the
a✓a✓a✓at✓t✓t✓tt✓t✓t✓ta✓a✓a✓ac✓c✓c✓ch✓h✓h✓h command for the interface.

_✓1._✓2.  _✓A_✓X_✓2_✓5 _✓P_✓a_✓r_✓a_✓m_✓e_✓t_✓e_✓r_✓s

_✓1._✓2._✓1.  _✓P_✓a_✓c_✓l_✓e_✓n

Paclen limits the size of the data  field  in  an  AX.25  I-
frame. This value does _✓n_✓o_✓t include the AX.25 protocol header
(source, destination and digipeater addresses).

Since unconnected-mode (datagram) AX.25 uses UI frames, this
parameter has no effect in unconnected mode.

The default value of p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n in NET is 256 bytes.

_✓1._✓2._✓2.  _✓M_✓a_✓x_✓f_✓r_✓a_✓m_✓e

This parameter controls the number of I-frames that NET  may
send on an AX.25 connection before it must stop and wait for
an acknowledgement.  Since the  AX.25/LAPB  sequence  number
field is 3 bits wide, this number cannot be larger than 7.

Since unconnected-mode (datagram) AX.25 uses UI frames  that
do  not have sequence numbers, this parameter does _✓n_✓o_✓t apply
to unconnected mode.

The default value of m✓m✓m✓ma✓a✓a✓ax✓x✓x✓xf✓f✓f✓fr✓r✓r✓ra✓a✓a✓am✓m✓m✓me✓e✓e✓e in NET is 1 frame.

_✓1._✓3.  _✓I_✓P _✓a_✓n_✓d _✓T_✓C_✓P _✓P_✓a_✓r_✓a_✓m_✓e_✓t_✓e_✓r_✓s

                        June 3, 1990

                           - 2 -

_✓1._✓3._✓1.  _✓M_✓T_✓U

The MTU (Maximum Transmission Unit) is an interface  parame-
ter  that limits the size of the largest IP datagram that it
may handle.  IP datagrams routed to an  interface  that  are
larger  than  its  MTU are each split into two or more _✓f_✓r_✓a_✓g_✓-
_✓m_✓e_✓n_✓t_✓s.  Each fragment has its own IP header and  is  handled
by  the  network  as  if it were a distinct IP datagram, but
when it arrives at the destination it  is  held  by  the  IP
layer until all of the other fragments belonging to the ori-
ginal datagram have arrived. Then they are reassembled  back
into the complete, original IP datagram. The minimum accept-
able interface MTU is 28 bytes: 20 bytes for the  IP  (frag-
ment) header, plus 8 bytes of data.

There is no default MTU in NET; it must be explicitly speci-
fied for each interface as part of the a✓a✓a✓at✓t✓t✓tt✓t✓t✓ta✓a✓a✓ac✓c✓c✓ch✓h✓h✓h command.

_✓1._✓3._✓2.  _✓M_✓S_✓S

MSS (Maximum Segment Size) is  a  TCP-level  parameter  that
limits the amount of data that the _✓r_✓e_✓m_✓o_✓t_✓e TCP will send in a
single TCP packet. MSS values are exchanged in the SYN (con-
nection  request) packets that open a TCP connection. In the
NET implementation of TCP, the MSS actually used by  TCP  is
further reduced in order to avoid fragmentation at the local
IP interface. That is, the local TCP asks IP for the MTU  of
the interface that will be used to reach the destination. It
then subtracts 40 from the MTU value to allow for the  over-
head  of  the TCP and IP headers. If the result is less than
the MSS received from the remote TCP, it is used instead.

The default value of M✓M✓M✓MS✓S✓S✓SS✓S✓S✓S in NET is 512 bytes.

_✓1._✓3._✓3.  _✓W_✓i_✓n_✓d_✓o_✓w

This is a TCP-level parameter that controls  how  much  data
the  local  TCP  will allow the remote TCP to send before it
must stop and wait for an acknowledgement. The actual window
value  used  by TCP when deciding how much more data to send
is referred to as the _✓e_✓f_✓f_✓e_✓c_✓t_✓i_✓v_✓e _✓w_✓i_✓n_✓d_✓o_✓w.  This is the smaller
of two values: the window advertised by the remote TCP minus
the unacknowledged data in flight, and the  _✓c_✓o_✓n_✓g_✓e_✓s_✓t_✓i_✓o_✓n  _✓w_✓i_✓n_✓-
_✓d_✓o_✓w,  an automatically computed time-varying estimate of how
much data the network can handle.

The default value of W✓W✓W✓Wi✓i✓i✓in✓n✓n✓nd✓d✓d✓do✓o✓o✓ow✓w✓w✓w in NET is 2048 bytes.

_✓1._✓4.  _✓D_✓i_✓s_✓c_✓u_✓s_✓s_✓i_✓o_✓n

                        June 3, 1990

                           - 3 -

_✓1._✓4._✓1.  _✓I_✓P _✓F_✓r_✓a_✓g_✓m_✓e_✓n_✓t_✓a_✓t_✓i_✓o_✓n _✓v_✓s _✓A_✓X._✓2_✓5 _✓S_✓e_✓g_✓m_✓e_✓n_✓t_✓a_✓t_✓i_✓o_✓n

IP-level fragmentation often makes it possible to  intercon-
nect  two  dissimilar networks, but it is best avoided when-
ever possible.  One reason is that when a single IP fragment
is  lost, all other fragments belonging to the same datagram
are effectively also lost and the entire  datagram  must  be
retransmitted  by  the source.  Even without loss, fragments
require the allocation of temporary  buffer  memory  at  the
destination, and it is never easy to decide how long to wait
for missing fragments before giving up and discarding  those
that have already arrived.  A reassembly timer controls this
process.  In NET it is (re)initialized with  the  i✓i✓i✓ip✓p✓p✓p  r✓r✓r✓rt✓t✓t✓ti✓i✓i✓im✓m✓m✓me✓e✓e✓er✓r✓r✓r
parameter  (default 30 seconds) whenever progress is made in
reassembling a datagram (i.e., a new fragment is  received).
It is not necessary that all of the fragments belonging to a
datagram arrive within a single timeout interval, only  that
the interval between fragments be less than the timeout.

Most subnetworks that carry IP have MTUs  of  576  bytes  or
more,   so  interconnecting  them  with  subnetworks  having
smaller values can result in considerable fragmentation. For
this  reason,  IP implementors working with links or subnets
having unusually small packet size limits are encouraged  to
use _✓t_✓r_✓a_✓n_✓s_✓p_✓a_✓r_✓e_✓n_✓t _✓f_✓r_✓a_✓g_✓m_✓e_✓n_✓t_✓a_✓t_✓i_✓o_✓n, that is, to devise schemes to
break up large IP datagrams into a sequence of link or  sub-
net frames that are immediately reassembled on the other end
of the link or subnet into the original, whole  IP  datagram
without  the use of IP-level fragmentation. Such a scheme is
provided in AX.25 Version 2.1.  It can break a large  IP  or
NET/ROM  datagram  into  a series of p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n-sized AX.25 seg-
ments (not to be confused with TCP segments), one per  AX.25
I-frame,  for transmission and reassemble them into a single
datagram at the other end of the link before handing  it  up
to  the  IP or NET/ROM module.  Unfortunately, the segmenta-
tion procedure is a new feature in  AX.25  and  is  not  yet
widely  implemented;  in  fact, NET is so far the only known
implementation. This creates some interoperability  problems
between  NET  and  non-NET  nodes,  in  particular, standard
NET/ROM nodes being used to carry IP datagrams. This problem
is discussed further in the section on setting the MTU.

_✓1._✓4._✓2.  _✓S_✓e_✓t_✓t_✓i_✓n_✓g _✓p_✓a_✓c_✓l_✓e_✓n _✓a_✓n_✓d _✓b_✓u_✓f_✓s_✓i_✓z_✓e

The more data you put into an AX.25 I frame, the smaller the
AX.25  headers  are  in relation to the total frame size. In
other words, by increasing p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n, you lower the AX.25  pro-
tocol overhead. Also, large data packets reduce the overhead
of keying up a transmitter, and this  can  be  an  important
factor  with  higher  speed modems. On the other hand, large
frames make bigger targets for noise and interference.  Each
link  has an optimum value of p✓p✓p✓pa✓a✓a✓ac✓c✓c✓cl✓l✓l✓le✓e✓e✓en✓n✓n✓n that is best discovered
by experiment.

                        June 3, 1990

                           - 4 -

Another thing to remember when setting p✓p✓p✓pa✓a✓a✓ac✓c✓c✓